You remove a Docker image using the docker rmi command followed by the image name, ID, or tag, but only if the image is not being used by any running or stopped containers.
The docker rmi (remove image) command deletes Docker images from your local system. An image can only be removed if it's not in use by any container—running or stopped. If an image has multiple tags, you must remove all tags or use the -f flag to force removal. Proper image management is essential for controlling disk space, as Docker images can accumulate quickly, especially during development where multiple versions are built repeatedly.
If you attempt to remove an image that is in use, Docker will display an error: Error response from daemon: conflict: unable to remove repository reference "my-app:latest" (must force) - container X is using its referenced image. This occurs even if the container is stopped. You have three options: remove the container first with docker rm, use docker rmi -f to force removal (which also removes the associated stopped container), or if the container is running, you must stop and remove it first.
The docker image prune command provides a safer cleanup alternative. Without options, it removes only dangling images (those with no tags and not referenced by any container). Adding -a removes all unused images—any image not currently referenced by a container. This is useful for clearing disk space after many builds, as unused intermediate layers and old versions accumulate. You can preview what would be removed with docker image prune --dry-run.
docker rmi my-app:latest - Remove a specific tagged image
docker rmi $(docker images -f "dangling=true" -q) - Remove all dangling images (untagged)
docker image prune -a - Remove all images not in use (aggressive cleanup)
docker system prune -a - Comprehensive cleanup: images, containers, volumes, networks
docker rmi $(docker images --filter "before=my-app:v1.0" -q) - Remove all images built before a specific version
When building images frequently in CI/CD or development, old images can consume gigabytes of disk space. Best practices include: using --rm when running containers to prevent them from lingering, regularly running docker image prune -a in development environments, and implementing retention policies to keep only recent images. For production environments, use image tagging strategies with unique identifiers (like commit SHAs) rather than overwriting tags like latest, which prevents the need to force-remove images still referenced by stopped containers.
You have a local image called myapp:latest that you no longer need. Walk me through the exact command you would use to delete it and what you would check first.
If Docker refuses to remove an image because it’s being used by a container, what steps would you take to resolve the situation?
What happens when you run docker rmi on an image that has multiple tags, and how does Docker handle those tags?
Your CI pipeline fails because a build step tries to pull an image that was removed locally, resulting in a ‘image not found’ error. How would you debug and fix this?
You notice docker image prune is deleting images needed for a staging environment. How would you adjust the command or workflow to avoid that while still cleaning up unused images?
A developer accidentally pushed a large, vulnerable base image to your private registry. Explain how you would remove it from all developer machines and prevent it from being pulled again.
In a large microservices deployment, each service builds its own Docker image daily, leading to thousands of images on the build servers. Design a strategy to safely prune images without disrupting running services, considering dependencies and storage constraints.
Your organization uses a shared Docker registry with retention policies. How would you implement an automated process to remove images older than a certain age while ensuring any images still referenced by deployed containers are retained?
Explain the trade‑offs between using docker rmi versus docker system prune in a high‑throughput CI environment, especially regarding performance impact and risk of accidental deletion.
You are leading a migration from an on‑premises Docker registry to a cloud‑based artifact store. Part of the migration requires cleaning up legacy images across many clusters without downtime. Outline the architectural approach you would take, including coordination, safety checks, and rollback plans.
How would you design a cross‑team policy and tooling for image lifecycle management that balances security (removing vulnerable images), cost (storage), and developer autonomy, and how would you enforce it at scale?